home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 11⁄24⁄89 / 0106-C++ for systems prog-Nov89 next >
Encoding:
Text File  |  1989-11-24  |  2.6 KB  |  65 lines  |  [TEXT/GEOL]

  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    8795939                         19-Nov-89        02:50
  4.  
  5. From:   UK0310                          Paul G Smith
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. cc:     SHEBANOW1                       Shebanow, Andrew
  10.  
  11. Sub:    C++ for systems programming
  12.  
  13. Use of C++ for stand-alone code resources...
  14.  
  15. (This message would have been posted to CPlus.Tech$ if that list was active
  16. yet. It isn't, as far as I know, and MacApp.Tech$ seems the next best!)
  17.  
  18.  
  19. I figured it would be pretty neat to be able to produce stand-alone code
  20. resources using MPW C++. I'd always wanted to do it with Object Pascal and it
  21. seemed like C++ would allow me do develop low level stuff using OOP principles.
  22. So, I set about building a generic OOP shell for certain kinds of stand-alone
  23. code resource, using MPW C++.
  24.  
  25. Almost immediately I ran up against some problems that I should have been able
  26. to predict before I started. However, it would be nice to know if there is any
  27. way around these problems, because C++ is such an ideal language for systems
  28. programming and it really is about time such work could be done the OOP way.
  29.  
  30. C++ can be used to build stand-alone code resources if the following three
  31. restrictions are noted:
  32.  
  33. {i} You cannot use anything except stack allocated objects. For instance, if
  34. you try to use new to create an object, the linker complains because the data
  35. initialisation code is not being called.
  36.  
  37. {ii} You cannot define or use constructors or destructors. If you do, the
  38. linker complains as in {i} above.
  39.  
  40. {iii} You cannot use virtual member functions. If you do, the linker complains
  41. as in {i} & {ii} above.
  42.  
  43. The is all very well, but it means that you can only have one level of objects,
  44. that you can't allocate them in the heap, and that the expressiveness of C++ is
  45.  lost.
  46.  
  47. The thing is, I don't see that we are talking about inherent limitations of C++
  48. here. There is no reason, other than implementation decisions relating to the
  49. MPW version of C++, why one should not be able to build stand-alone code
  50. resources using the full expressiveness of C++. It strikes me that if this
  51. limitation was removed one could also develop for the MCP (and other 68K
  52. platforms) using C++.
  53.  
  54. So, my question is:
  55.  
  56. What can I do to force *all* the output - including constrctors, destructors,
  57. and all the other run-time support code - of the MPW C++ compilation system to
  58. end up in the *same* segment and to ensure that all the right code gets called.
  59. I am quite happy to build the necessary support routines (and publish them in
  60. due course), but I can't until I know what to do. Can anyone help??
  61.  
  62. Regards, Paul
  63.  
  64.  
  65.